Replace blacklist with blocklist #746
Conversation
|
Hey @mmoll I was curious if you could expand upon your reaction here? This is an entirely new area for me, and perhaps for a lot of us, so any opinions on this would be valuable so that we can take all points into consideration. |
|
I'm not going to interfere in any way pulling in these newspeak renamings, but as I tried to outline two times in the discussion about having a "code of conduct" I find it super wrong to have politics coming into technical projects. |
|
Thanks @mmoll - I remember reading that and will go back and refresh myself on those points. I appreciate your response! Thank you. |
There is nothing "political", in a left-right sense, about making it less painful and frustrating for others to use software and contribute back to it. |
|
The Foreman’s Community Guidelines state: “Be nice: Treat people with respect and consideration.” We have a strong, healthy and respectful community who can always do better to be more inclusive to new contributors. This includes language, and terminology in our code base and documentation. There are simple actions we can take that can help remove some of the terms that a growing set of projects and organizations are coming into agreement that go against the goals of inclusivity for our contributors. The common argument is that the use of “whitelist/blacklist” in these technological contexts are not racist, and I recognize that the origin may or may not have been intended to be so. The semantic details of language matter less than the potential impact it may have, intended or otherwise. Proposing this verbiage change is a small move that will benefit some and will not actively harm others, therefore it is a change worth investing in, even if it is a small drop in the bucket that is the ocean we must address as a society. +1 from me to make this change and as it is a small but positive movement to help remove politics from the project by choosing more neutral terms. |
|
I think this is a bad idea right now because the actual parameter is blacklist (at least for now). blacklist and blocklist is easy to confuse, especially for dyslexic people (another minority). https://www.theregister.com/2020/06/15/github_replaces_master_with_main/ also states:
I'd say we wait for the linux kernel to change and then follow that naming. This avoids confusion for users, especially if we need to rename twice. |
|
Wishing the new contributors all the best then. 👋 |
|
@lzap: the change should not only rename the use in templates, but it should also rename the parameter name. I agree with what @ekohl says, we don't need to rush this in, I'd like to avoid renaming it after kernel changes it. As @melcorr suggested, we can publish our intent on the blog post and explain, why we don't change the parameter name now. Also we'll probably need to support both kernel parameters for a while, there will be systems with old kernel for a long time. off-topic, but this PR already discuss the broader topic This overall change gets a bit more complicated on foreman_virt_who_plugin, where these terms are part of API. Virt-who config itself uses terms filter, exclude which we can adjust to, however we should probably keep the API compatible for a while. |
|
Hi, I'm vocal against this change too. There's no benefit at all doing this instead of breaking compatibility and confuse people with blacklist/blocklist everywhere. You'll never know when to use the right keyword or where. Even my browser language speller changed blocklist to blacklist when I was typing it here. Breaking software just to push an agenda is just a waste of effort and everyone's time. I do not intend to offend anyone here since I'm a consumer of The Foreman, but this changes are just like green-washing. It does not solves any real issue, and I really question if this changes aren't something like the "white savior guy" doing something to pet and care about those who aren't Caucasians. This kind of move is a little bit offensive to be honest. |
|
+1 to holding off on this PR and waiting for the kernel naming scheme decision. If we do decide to rename, we only want to do it once. |
|
On behalf of the Foreman team, thank you for your contribution to the Foreman community templates repository! |
I was taught in schools and books about whitelist and blacklist technical terms. It felt natural and normal to me, until last couple of days. Latest developments from US and all over the world made me to realize how awful these words are. While these words might not associate anything to some of us, there are many out there who might not feel the same. Getting rid of these may be just a small gesture, but I don't want to sit doing nothing.
The patch I propose removes "blacklist" and "blacklist_kernel_modules" host parameters and replaces both with one called "blocklist_kernel_parameter". They both served the same purpose - to pass either kernel command line option
blacklistand/or create entry in/etc/modprobe.d/blacklist.conf. Insted of two host params we now have a single one. On top of that, the syntax is now common, kernel modules can be separated with a comma or a whitespace, previously it was different for both parameters.While we cannot get rid of the
blacklistkeyword in the rendered output because Linux expect these keywords as of today (summer 2020), we can trim down the exposure at least for Foreman users. That's something. In the initial proposal, using any of the previous host parameters will cause an exception asking the user to change their templates. We can talk about that, we don't have any deprecation mechanisms for templates (yet), I can create a macro calleddeprecatedwhich drops a warning message in logs although I have doubts users would catch that until we finally drop it.